The present invention relates generally to creating and executing application programs and other software and, particularly, to methods for improved execution of such programs in a distributed environment.
With the explosive growth of the Internet and the World Wide Web, an ever-increasing number of computers of disparate platforms are being connected together. As a result, there is renewed interest in distributing software in binary format which operates in this ever-increasing heterogeneous environment.
Porting programs from one platform to another has always been problematic, however. In the recent past, for example, developers relied on programming languages which were "relatively portable," such as ANSI C, for developing software applications. While some degree of portability can be achieved using C, minute differences between platforms (even between dialects of UNIX) mandate that the software be recompiled for the particular operating environment where the software application is to be deployed.
In the early 1990s, a team at Sun Microsystems developed a new language, "Java," to address the issues of software distribution on the Internet. Java is a simple, object-oriented language which supports multi-thread processing and garbage collection. Although the language is based on C++, a superset of C, it is much simpler. More importantly, Java programs are "compiled" into a binary format that can be executed on many different platforms without recompilation. The language includes built-in mechanisms for verifying and executing Java "binaries" in a controlled environment, protecting the user's computer from potential viruses and security violations.
A typical Java system comprises the following set of interrelated technologies: a language specification; a compiler for the Java language that produces bytecodes from an abstract, stack-oriented machine; a virtual machine (VM) program that interprets the bytecodes at runtime; a set of class libraries; a runtime environment that includes bytecode verification, multi-threading, and garbage collection; supporting development tools, such as a bytecode disassembler; and a browser (e.g., Sun's "Hot Java" browser).
Java is designed for creating applications that will be deployed into heterogeneous networked environments. Such environments are characterized by a variety of hardware architectures. Further, applications in such environments execute atop a variety of different operating systems and interoperate with a multitude of different programming language interfaces. To accommodate such diversity, the Java compiler generates platform-neutral "bytecodes"--an architecturally neutral, intermediate format designed for deploying application code efficiently to multiple platforms.
Java bytecodes are designed to be easy to interpret on any machine. Bytecodes are essentially high-level, machine-independent instructions for a hypothetical or "virtual" machine that is implemented by the Java interpreter and runtime system. The virtual machine, which is actually a specification of an abstract machine for which a Java language compiler generates bytecode, must be available for the various hardware/software platforms which an application is to run. The Java interpreter executes Java bytecode directly on any machine for which the interpreter and runtime system of Java have been ported. In this manner, the same Java language bytecode runs on any platform supported by Java.
Compiling Java into platform-neutral bytecodes is advantageous. Once the Java language interpreter and runtime support are available on a given hardware and operating system platform, any Java language application can be executed. The bytecodes are portable since they do not require a particular processor, architecture, or other proprietary hardware support. Further, the bytecodes are byte-order independent, so that programs can be executed on both big-endian machines (e.g., Intel architecture) and little-endian machines (e.g., Motorola architecture). Since Java bytecodes are typed, each specifies the exact type of its operands, thereby allowing verification that the bytecodes obey language constraints. All told, the interpreted bytecode approach of compiled Java language programs provides portability of programs to any system on which the Java interpreter and runtime system have been implemented.
The bytecodes are actually stored in "class" files. Each class file stores all the information for a particular Java class. A "class" in Java is a software construct which defines instance variables and methods, in effect, serving as a template for creating objects of a particular type. In this regard, a Java class is akin to a C++ class. A very simple "Point" class, for instance, may be declared as follows.
______________________________________ class Point { public double x; /* instance variable */ public double y; /* instance variable */ ______________________________________
This declaration serves as a template from which "Point" objects can be instantiated.
Actual instantiation of an object occurs in a manner similar to that found in the C++ programming language. For example, a variable which refers to a "Point" object can be declared as follows:
Point myPoint; PA1 myPoint=new Point (); PA1 myPoint.x=10; PA1 myPoint.y=20;
An instance of a point object is allocated as follows.
Here, one can now access variables of the "Point" object, using familiar "dot" notation for referring to the names of the variables.
Objects communicate by sending messages to each other. A recipient object responds to a message by selecting a particular method to execute. If one object wants another object to do some work on its behalf, for instance, the first object sends a message to the second object. The second object, in response, invokes the method which is appropriate for processing the message. The methods themselves, therefore, define the behavior of objects instantiated from a class. In particular, it is an object's methods which manipulate the object's data--its instance variables.
Further description of the Java Language environment can be found in Gosling, J. et al., The Java Language Environment: A White Paper, Sun Microsystems Computer Company, October 1995, the disclosure of which is hereby incorporated by reference.
Relying on a runtime interpreter for execution, Java applications execute notoriously slow. One approach to improving the execution performance of a Java application is to pre-compile the application's bytecode into native machine code for a particular platform and store that code in the corresponding class file. The approach has distinct disadvantages, however. For instance, the class file now becomes machine dependent, since it incorporates machine code for a particular platform. As there are many different platforms available, it is not practical to include compiled machine code in a class file for each and every platform.
There are other disadvantages. Including pre-compiled code within the class file itself leads to a much larger class file, even when just a single platform is targeted. As Java applications are largely targeted for Internet deployment, increased program size is highly undesirable: increased download times result. As another disadvantage, pre-compiled code potentially compromises security. Although the Java environment provides built-in security, such security checks are performed on Java bytecode. There are no provisions for checking code once it is no longer in bytecode format. As yet another disadvantage, pre-compiled code is not position independent (i.e., positioned in system memory). In order to relocate pre-compiled code at runtime, memory address fix-ups are required. This stems from the fact that the system does not know beforehand where (i.e., what memory address) the pre-compiled code will be loaded into system memory. Although it is relatively straightforward to do such fix-ups, the overhead incurred with such an operation is highly undesirable.
What is needed is a development system which provides the benefits of compiling Java applications into native machine code, yet without the disadvantages attendant with pre-compilation approaches. The present invention fulfills this and other needs.